home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98c.txt / 000007_icon-group-sender _Thu Sep 10 12:24:31 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  6KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA26222
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Thu, 10 Sep 1998 12:24:31 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA31099; Thu, 10 Sep 1998 12:24:04 -0700
  7. From: gep2@computek.net
  8. Date: Thu, 10 Sep 1998 13:46:57 -0500 (CDT)
  9. Message-Id: <199809101846.NAA18441@mail.cmpu.net>
  10. Mime-Version: 1.0
  11. Content-Type: text/plain
  12. Content-Transfer-Encoding: 7bit
  13. Subject: Unicode support or support for non-Ascii based character
  14.     manipulation?
  15. To: icon-group@optima.CS.Arizona.EDU
  16. X-Mailer: SPRY Mail Version: 04.00.06.17
  17. Content-Transfer-Encoding: 7bit
  18. Content-Transfer-Encoding: 7bit
  19. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  20. Content-Transfer-Encoding: 7bit
  21. Status: RO
  22.  
  23. > Icon has been a very interesting language for string manipulation,
  24.  
  25. Certainly!  If not the MOST interesting language for such purposes.
  26.  
  27. > however, the limit of supporting only ASCII 
  28.  
  29. Actually, that's not really true.  Icon is much more free of "supporting ONLY 
  30. ASCII" than C, for example.  (I don't know how true this is about things like 
  31. conversions... does Icon automatically support EBCDIC character assignments, for 
  32. example, if generated on an EBCDIC system?)
  33.  
  34. Certainly though there are issues that come up with supporting international 
  35. characters, and in part that's due to the fact that there doesn't seem to be any 
  36. real international agreement on how (at least some) other natural languages map 
  37. their alphabetic characters into (at least) an 8-bit byte.  Hebrew is one 
  38. example, where there seem to be at least three different competing "standards" 
  39. for where the characters are mapped.
  40.  
  41. > makes it less useful for non-English language work. 
  42.  
  43. Well, I agree that it's perhaps less useful than it MIGHT be, but I still 
  44. suspect it's (far!) more useful than OTHER programming languages are for these 
  45. kinds of things.
  46.  
  47. > With the computer industry heading towards Unicode support, 
  48.  
  49. Okay, I don't dispute that this move is happening but personally I still don't 
  50. very much like it.  The fact is that (at least here in the Western Hemisphere, 
  51. where probably most of the world's computers are used) an eight-bit byte is 
  52. already quite sufficient for most purposes, and doubling it comes at a cost in 
  53. complexity and storage (RAM, disk, tape, whatever) which is simply very, very 
  54. hard to justify on any genuine economic basis.  If other countries have more 
  55. difficult (or huge) character sets, that is (while a fact of life) simply an 
  56. inherent disadvantage of their culture (and note that I'm not intending that as 
  57. a slam or value judgement, it just IS the way it is), and I don't see a terribly 
  58. convincing argument why the other countries (without that disadvantage) ought to 
  59. pay the price too, just in order to artificially level the playing field.
  60.  
  61. > ...it should be possible to begin including support for
  62. non-English and non alphabetic languages. 
  63.  
  64. I think that a lot of the basic manipulations and features in Icon (tables, 
  65. sets, etc) are probably insensitive to the character mapping used.  And Icon 
  66. does seem to be pretty much (totally?) eight-bit clean (unlike C), which at 
  67. least gives one the ability to construct stuff on top of it to support other 
  68. languages.
  69.  
  70. One issue, of course, is the one I mentioned earlier... conversions, although 
  71. numeric formatting is one other specific example of a potential problem area.  
  72. Certainly not all cultures prefer Arabic numerals.  
  73.  
  74. Another issue, perhaps unique to Icon, is the implementation of "character set" 
  75. datatypes, which I'd suspect would end up being quite different for a language 
  76. containing 65,536 distinct characters... since the character set data 
  77. representation, presumably unless a different implementation technique were 
  78. used, would be not twice but 256 times larger than for an eight-bit character 
  79. set.  
  80.  
  81. I can certainly understand and appreciate the problems that the huge character 
  82. sets used in some eastern countries have played for them, and frankly have been 
  83. surprised by the extent to which solutions for things like keyboards have been 
  84. mastered.  And text processing with such large character sets certainly must 
  85. represent a whole series of unique challenges, so I can understand the interest 
  86. in those countries in something like Icon for attacking them.
  87.  
  88. > Has anyone thought about this yet? What does string and pattern matching
  89. mean in, for example, Japanese?
  90.  
  91. I have given the matter some thought, although just as an 'outside observer'.  I 
  92. would presume that a "full/nice" implementation for such languages would result 
  93. in simply processing Unicode-like 16-bit characters, with everything that 
  94. involves.  At *some* point, barring having complete 16-bit-byte uniformity 
  95. across everything from CPUs and operating systems to peripheral devices, there 
  96. might have to be some conversions and "glue" interface work done, and 
  97. classically it's at those border/edge regions that the seams tend to be less 
  98. than pretty.
  99.  
  100. Certainly one of the more interesting Icon-related issues I've seen come up here 
  101. in a while.  I seem to recall it was mentioned briefly some time ago (perhaps 
  102. that was on the SNOBOL4 list instead?) but didn't go very far at the time.
  103.  
  104. Gordon Peterson
  105. http://www.computek.net/public/gep2/
  106. Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
  107.  
  108.